Security Hub 検出結果のフィルタリング例
Security Hubで出てきた検出結果イベントを SNS, CloudWatch Events ルール (EventBridge) を介してメールや Slackチャンネルに投稿ができます。 が、特にフィルタ設定をしないとチェックの合格・不合格に関わらず通知が来るので重要な情報が埋もれがちです。
Security Hub 検出結果フィルタリング例をいくつか紹介します。
イベント周りの前提知識
Security Hub Findings - Imported
イベント
Security Hub は、すべての結果を Security Hub Findings - Imported イベントとして CloudWatch イベント に自動的に送信します。
主にこのイベントを Security Hubの結果通知に利用します。
AWS Security Finding 形式(ASFF)
Security Hubは定期的なチェックを行います。チェックの合格・不合格に関わらずイベントとなります。 なので、何もフィルタリングしない設定をした場合、大量の通知がきます。 運用で活用していくにはこれらイベントをフィルタリングする必要がでてきます。
Security Hubのイベントは AWS Security Finding 形式(ASFF) と呼ばれる JSON構文で格納されています。 この構文を基にフィルターを作成していきます。
EventBridge のフィルタリング方法の詳細は下記参照ください。
例1: セキュリティチェックに合格しなかった結果を取得する
Complianceオブジェクト にはセキュリティチェックの結果 ( Compliance.Status
) が含まれます。
ステータスの種類は以下の通りです。
値 | 内容 |
---|---|
PASSED | チェックに合格 |
WARNING | 不足している情報がある or チェックをサポートしていない |
FAILED | 1つ以上のリソースがチェックに合格しなかった |
NOT\_AVAILABLE | サービス停止もしくはAPIエラーにより、チェックを実行できなかった |
チェックに合格しなかったもの( PASSED
以外)を見たいケースがほとんどです。
その場合のフィルタ設定です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "RecordState": [ "ACTIVE" ] } } }
例2: 重要度が高い結果に絞って取得する
セキュリティチェックの結果には重要度 Severity.Label
の値が付与されます。
セキュリティチェックに合格 PASSED
している場合は INFORMATIONAL
となります。
不合格している、大きなセキュリティリスクを含んだ結果は CRITICAL
や HIGH
となります。
INFORMATIONAL
– 問題は見つかりませんでした。LOW
– この問題は単独で対処する必要はありません。MEDIUM
– この問題は対処する必要がありますが、緊急ではありません。HIGH
– この問題は優先事項として対処する必要があります。CRITICAL
– この問題は悪化しないようにすぐに修正する必要があります。
以下、
- 失敗した項目で
- 重要度の高い結果 (
CRITICAL
,HIGH
)
を通知するフィルタ設定です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "Severity": { "Label": [ "CRITICAL", "HIGH" ] }, "RecordState": [ "ACTIVE" ] } } }
例3: 「通知済み」にしたものは除外する
Security Hubによるセキュリティチェックは定期的に行われます。 つまり非準拠のリソースがあったときに、 そのリソースがチェックに合格しない限り定期的に通知され続けてしまいます。
何かしらの課題管理ツールへ起票して、対応中の状態でも通知されてしまうのは邪魔ですよね。
そこで、 ワークフローのステータス
を 通知済み にしたものは取得されないようにしてみます。
以下、
- 失敗した項目で
- 重要度の高い結果 (
CRITICAL
,HIGH
) かつ - ワークフローが
NEW
のもの
を通知するフィルタ設定です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "Severity": { "Label": [ "CRITICAL", "HIGH" ] }, "Workflow": { "Status": [ "NEW" ] }, "RecordState": [ "ACTIVE" ] } } }
※ ワークフローのステータス
は以下のようなコントロールの画面で変えられます。
例4: 「基礎セキュリティのベストプラクティス」のみ通知する
『通知は 基礎セキュリティのベストプラクティス
のみにしぼりたい』場合に活用できるフィルタ例です。
以下、
- 「基礎セキュリティのベストプラクティス」のセキュリティ基準内で
- 失敗した項目で
- 重要度の高い結果 (
CRITICAL
,HIGH
) かつ - ワークフローが
NEW
のもの
を通知するフィルタ設定です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "ProductFields":{ "StandardsArn": [ "arn:aws:securityhub:::standards/aws-foundational-security-best-practices/v/1.0.0" ] }, "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "Severity": { "Label": [ "CRITICAL", "HIGH" ] }, "Workflow": { "Status": [ "NEW" ] }, "RecordState": [ "ACTIVE" ] } } }
例5: 特定コントロールは通知しない
通知したくない場合、本来はコントロールを無効化すればよいのですが、 マルチアカウント構成で運用している場合は、EventBridge 側でフィルタしたほうが手間が省けることがあります。
以下、
- 「基礎セキュリティのベストプラクティス」のセキュリティ基準内の
S3.8, SNS.1
以外のコントロールについて- 失敗した項目で
- 重要度の高い結果 (
CRITICAL
,HIGH
) かつ - ワークフローが
NEW
のもの
を通知するフィルタ設定です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "ProductFields":{ "StandardsArn": [ "arn:aws:securityhub:::standards/aws-foundational-security-best-practices/v/1.0.0" ], "ControlId": [ { "anything-but": ["S3.8", "SNS.1"] } ] }, "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "Severity": { "Label": [ "CRITICAL", "HIGH" ] }, "Workflow": { "Status": [ "NEW" ] }, "RecordState": [ "ACTIVE" ] } } }
おわりに
Security Hub の結果通知のフィルタリング例を紹介してみました。 複数のフィルターを作成・試運用してみて、 適宜チューニングするのが良いと思います。
少しでもどなたかのお役に立てば幸いです。
参考
▼ Security Hub
▼ EvenntBridge
▼ Developers.IO